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Purpose  of  the  Scrum  Guide 

Scrum  is  a frame  work  for  developing  and  sustaining  complex  products.  This  Guide  contains  the 
definition  of  Scrum.  This  definition  consists  of  Scrum's  roles,  events,  artifacts,  and  the  rules  that 
bind  them  together.  Ken  Schwaber  and  Jeff  Sutherland  developed  Scrum;  the  Scrum  Guide  is 
written  and  provided  by  them.  Together,  they  stand  behind  the  Scrum  Guide. 


Definition  of  Scrum 

Scrum  (n):  A frame  work  within  which  people  can  address  complex  adaptive  problems,  while 
productively  and  creatively  delivering  products  of  the  highest  possible  value. 

Scrum  is: 

• Lightweight 

• Simpletounderstand 

• Difficultto  master 

Scrum  is  a process  framework  that  has  been  used  to  manage  complex  product  development 
since  the  early  1990s.  Scrum  is  not  a processor  a technique  forbuilding  products;  rather,  it  is  a 
framework  within  which  you  can  employ  various  processes  and  techniques.  Scrum  makes  clear 
the  relative  efficacy  of  your  product  management  and  development  practices  so  that  you  can 
improve. 

The  Scrum  framework  consists  of  Scrum  Teams  and  their  associated  roles,  events,  artifacts,  and 
rules.  Each  component  within  the  frame  work  serves  a specific  purpose  and  is  essential  to 
Scrum's  success  and  usage. 

The  rules  of  Scrum  bind  together  the  events,  roles,  and  artifacts,  governing  the  relationships  and 
interaction  between  them.  The  rules  of  Scrum  are  described  throughoutthe  bodyofthis 
document. 

Specific  tactics  for  using  the  Scrum  framework  vary  and  are  described  elsewhere. 


Scrum  Theory 

Scrum  is  founded  on  empirical  process  control  theory,  or  empiricism.  Empiricism  asserts  that 
knowledge  comes  from  experience  and  making  decisions  based  on  what  is  known.  Scrum 
employsan  iterative,  incremental  approach  tooptimizepredictabilityand control  risk. 

Three  pillars  uphold  every  implementation  of  empirical  process  control:  transparency, 
inspection,  and  adaptation. 
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Transparency 

Significant  aspects  of  the  process  must  be  visible  to  those  responsible  for  the  outcome. 
Transparency  requires  those  aspects  be  defined  by  a common  standard  so  observers  share  a 
common  understanding  of  what  is  being  seen. 

For  example: 

• A common  language  referringtothe  process  must  be  shared  by  all  participants;  and, 

• Those  performing  the  work  and  those  accepting  the  work  product  must  share  a common 
definition  of  "Done". 

Inspection 

Scrum  users  must  frequently  inspect  Scrum  artifacts  and  progress  toward  a Sprint  Goal  to  detect 
undesirable  variances.  Their  inspection  should  not  be  so  frequent  that  inspection  gets  in  the  way 
of  the  work.  Inspections  are  most  beneficial  when  diligently  performed  by  skilled  inspectors  at 
the  point  of  work. 

Adaptation 

If  an  inspector  determines  that  one  or  more  aspects  of  a process  deviate  outside  acceptable 
limits,  andthatthe  resultingproduct  will  be  unacceptable,  the  processorthe  material  being 
processed  must  be  adjusted.  An  adjustment  must  be  made  as  soon  as  possible  to  minimize 
furtherdeviation. 

Scrum  prescribesfourformal  events  for  inspection  and  adaptation,  asdescribed  intheScrum 
Events  section  of  this  document: 

• Sprint  Planning 

• DailyScrum 

• Sprint  Review 

• Sprint  Retrospective 


Scrum  Values 

When  the  values  of  commitment,  courage,  focus,  openness  and  respect  are  embodied  and  lived 
by  the  Scrum  Team,  the  Scrum  pillars  of  transparency,  inspection,  and  adaptation  come  to  life 
and  build  trust  for  everyone.  The  Scrum  Team  members  learn  and  explore  thosevaluesasthey 
work  with  the  Scrum  events,  roles  and  artifacts. 

Successful  use  of  Scrum  depends  on  people  becoming  more  proficient  in  living  these  five  values. 
People  personally  commit  to  achieving  the  goals  of  the  Scrum  Team.  The  Scrum  Team  members 
have  courage  to  do  the  right  thing  and  work  on  tough  problems.  Everyone  focuses  on  the  work 
of  the  Sprint  and  the  goals  of  the  Scrum  Team.  The  Scrum  Team  and  its  stakeholders  agree  to  be 
open  about  all  the  work  and  the  challenges  with  performing  the  work.  Scrum  Team  members 
respecteach  otherto  be  capable,  independent  people. 
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The  Scrum  Team 

The  Scrum  Team  consists  of  a Product  Owner,  the  Development  Team,  and  a Scrum  Master. 
Scrum  Teams  are  self-organizing  and  cross-functional.  Self-organizing  teams  choose  how  best  to 
accomplish  their  work,  rather  than  being  directed  by  others  outside  the  team.  Cross-functional 
teams  have  all  competencies  needed  to  accomplish  the  work  without  depending  on  others  not 
part  of  the  team.  The  team  model  in  Scrum  is  designed  to  opti mize  flexibility,  creativity,  and 
productivity. 

Scrum  Teams  deliverproducts  iteratively  and  incrementally,  maximizingopportunitiesfor 
feedback.  Incremental  deliveries  of  "Done"  productensure  a potentially  useful  version  of 
working  product  is  always  available. 

The  Product  Owner 

The  Product  Owner  is  responsible  for  maximizing  the  value  of  the  product  and  the  work  of  the 
Development  Team.  How  this  is  done  may  vary  widely  across  organizations,  Scrum  Teams,  and 
individuals. 

The  Product  Owner  is  the  sole  person  responsible  for  managing  the  Product  Backlog.  Product 
Backlog  management  includes: 

• Clearly  expressing  Product  Backlog  items; 

• Ordering  the  items  in  the  Product  Backlog  to  best  achieve  goals  and  missions; 

• Optimizingthe  valueofthe  work  the  DevelopmentTeam  performs; 

• Ensuring  that  the  Product  Backlog  is  visible,  transparent,  and  clear  to  all,  and  shows  what 
the  Scrum  Team  will  workon  next;  and, 

• Ensuring  the  DevelopmentTeam  understands  items  in  the  Product  Backlog  to  the  level 
needed. 

The  Product  Owner  may  do  the  above  work,  or  have  the  DevelopmentTeam  do  it.  However,  the 
Product  Owner  re  mains  accountable. 

The  Product  Owner  is  one  person,  not  a committee.  The  Product  Owner  may  re  present  the 
desires  of  a committee  in  the  Product  Backlog,  but  those  wanting  to  change  a Product  Backlog 
item's  priority  must  address  the  Product  Owner. 

For  the  Product  Owner  to  succeed,  the  entire  organization  must  respect  his  or  her  decisions.  The 
Product  Owner's  decisions  are  visible  in  the  content  and  ordering  of  the  Product  Backlog.  No 
one  is  allowed  to  tel  I the  DevelopmentTeam  to  work  from  a different  set  of  requirements,  and 
the  DevelopmentTeam  isn'tallowed  to  acton  whatanyone  else  says. 
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The  Development  Team 

The  Development  Team  consists  of  professionals  who  do  the  work  of  delivering  a potentially 
releasable  Increment  of  "Done"  product  at  the  end  of  each  Sprint.  Only  members  ofthe 
Development  Team  create  the  Increment. 

DevelopmentTeams  are  structured  and  empowered  by  the  organization  to  organize  and 
manage  their  own  work.  The  resulting  synergy  optimizes  the  Development  Team's  overall 
efficiency  and  effectiveness. 

DevelopmentTeams  have  the  followingcharacteri sties: 

• They  are  self-organizing.  No  one  (not  even  the  Scrum  Master)  tel  Is  the  Development  Team 
howto  turn  Product  Backlog  into  Increments  of  potentially  re  leasable  functionality; 

• DevelopmentTeams  are  cross-functional,  with  all  ofthe  skills  as  a team  necessary  to  create 
a product  Increment; 

• Scrum  recognizes  notitlesforDevelopmentTeam  members otherthan  Developer, 
regardless  ofthe  work  being  performed  by  the  person;  there  are  no  exceptions  to  this  rule; 

• Scrum  recognizes  no  sub-teams  in  the  Development  Team,  regardless  of  particular  domains 
that  need  to  be  addressed  I ike  testing  or  business  analysis;  the  re  are  no  exceptions  to  this 
rule;  and, 

• Individual  Development  Team  members  may  have  specialized  skills  and  areas  of  focus,  but 
accountability  belongs  to  the  Development  Team  as  a whole. 

Development  Team  Size 

Optimal  Development  Team  size  is  small  enough  to  remain  nimble  and  large  enough  to 
complete  significant  work  within  a Sprint.  Fewer  than  three  Development  Team  members 
decrease  interaction  and  results  in  smaller  productivity  gains.  Smaller  DevelopmentTeams  may 
encounter  ski  1 1 constraints  during  the  Sprint,  causing  the  Development  Team  to  be  unable  to 
delivera  potentially  releasable  Increment.  Flaving  more  than  nine  members  requires  too  much 
coordination.  Large  DevelopmentTeamsgeneratetoo  much  complexity foran  empirical  process 
to  manage. The  Product Ownerand  Scrum  Master  rolesare  notincluded  inthiscountunless 
they  are  also  executing  the  work  of  the  Sprint  Backlog. 

The  Scrum  Master 

The  Scrum  Master  is  responsible  forensuring Scrum  is  understood  and  enacted.  Scrum  Masters 
do  this  by  ensuring  that  the  Scrum  Team  adheres  to  Scrum  theory,  practices,  and  rules. 

The  Scrum  Master  is  a servant-leaderforthe  ScrumTeam.  The  Scrum  Master  helps  those 
outside  the  ScrumTeam  understand  which  of  their  interactions  with  the  ScrumTeam  are  helpful 
and  which  aren't.  The  Scrum  Master  helps  everyone  change  these  interactions  to  maximize  the 
value  created  by  the  Scrum  Team. 
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Scrum  Master  Service  to  the  Product  Owner 

The  Scrum  Master  serves  the  Product  Ownerin  several  ways,  including: 

• Finding  techniques  for  effective  Product  Backlog  management; 

• Helping  the  Scrum  Team  understand  the  need  for  cl  ear  and  concise  Product  Backlog  items; 

• Understanding  product  planning  in  an  empirical  environment; 

• Ensuring  the  Product  Owner  knows  howto  arrange  the  Product  Backlog  to  maximize  value; 

• Understandingand  practicingagility;  and, 

• Facilitating  Scrum  events  as  requested  or  needed. 

Scrum  Master  Service  to  the  DevelopmentTeam 

The  Scrum  Master  serves  the  DevelopmentTeam  in  several  ways,  including: 

• Coachingthe  DevelopmentTeam  in  self-organization  and  cross-functionality; 

• Helpingthe  DevelopmentTeam  to  create  high-value  products; 

• Re  moving  impediments  to  the  Development  Team's  progress; 

• FacilitatingScrum  events  as  requested  orneeded;  and, 

• Coachingthe  DevelopmentTeam  in  organizational  environments  in  which  Scrum  is  not  yet 
fully  adopted  and  understood. 

Scrum  Master  Service  to  the  Organization 

The  Scrum  Master  serves  the  organization  in  several  ways,  including: 

• Leading  and  coachingthe  organization  in  its  Scrum  adoption; 

• PlanningScrum  implementations  within  the  organization; 

• Helping  employees  and  stakeholders  understand  and  enact  Scrum  and  empirical  product 
developme  nt; 

• Causing  change  that  increases  the  productivity  of  the  Scrum  Team;  and, 

• Working  with  otherScrum  Masters  to  increase  the  effectiveness  of  the  application  of  Scrum 
in  the  organization. 


Scrum  Events 

Prescribed  events  are  used  in  Scrum  to  create  regularity  and  to  minimize  the  need  for  meetings 
not  defined  in  Scrum.  All  events  are  time-boxed  events,  such  that  every  event  has  a maximum 
duration.  Once  a Sprint  begins,  itsduration  isfixed  and  cannot  be  shortened  orlengthened.  The 
remaining  events  may  end  whenever  the  purpose  of  the  event  is  achieved,  ensuring  an 
appropriate  amount  of  time  is  spent  without  allowing  waste  in  the  process. 

Other  than  the  Sprint  itself,  which  is  a container  for  all  other  events,  each  event  in  Scrum  is  a 
formal  opportunity  to  inspect  and  adapt  something.  These  events  are  specifically  designed  to 
enable  critical  transparency  and  inspection.  Failure  to  include  any  of  these  events  results  in 
reduced  transparency  and  is  a lost  opportunity  to  inspect  and  adapt. 
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The  Sprint 

The  heart  of  Scrum  is  a Sprint,  a time-box  of  one  month  or  I ess  during  which  a "Done",  useable, 
and  potentially  releasable  product  Increment  is  created.  Sprints  best  have  consistent  durations 
throughout  a development  effort.  A new  Sprint  starts  immediately  after  the  conclusion  of  the 
previousSprint. 

Sprints  contain  and  consist  of  the  Sprint  Planning,  Daily  Scrums,  the  development  work,  the 
Sprint  Review,  and  the  Sprint  Retrospective. 

Duringthe  Sprint: 

• No  changes  are  made  that  would  endanger  the  Sprint  Goal; 

• Quality  goals  do  not  decrease;  and, 

• Scope  may  be  clarified  and  re-negotiated  between  the  Product  Owner  and  Development 
Team  as  more  is  learned. 

Each  Sprint  may  be  considered  a project  with  no  more  than  a one-month  horizon.  Like  projects, 
Sprints  are  used  to  accomplish  something.  Each  Sprint  has  a definition  of  what  is  to  be  built,  a 
design  and  flexible  plan  that  will  guide  building  it,  the  work,  and  the  resultant  product. 

Sprints  are  limited  to  one  calendar  month.  When  a Sprint's  horizon  is  too  long  the  definition  of 
what  is  being  built  may  change,  complexity  may  rise,  and  risk  may  increase.  Sprints  enable 
predictability  by  ensuring  inspection  and  adaptation  of  progress  toward  a Sprint  Goal  at  least 
every  calendar  month.  Sprints  also  limit  risk  to  one  calendar  month  of  cost. 

Cancelling  a Sprint 

A Sprint  can  be  cancelled  before  the  Sprint  time-box  is  over.  Only  the  Product  Owner  has  the 
authority  to  cancel  the  Sprint,  although  he  or  she  may  do  so  under  influence  from  the 
stakeholders,  the  DevelopmentTeam,  orthe  Scrum  Master. 

A Sprint  would  be  cancelled  if  the  Sprint  Goal  becomes  obsolete.  This  might  occur  if  the 
company  changes  direction  or  if  market  or  technology  conditions  change.  In  general,  a Sprint 
should  be  cancelled  if  it  no  longer  makes  sense  given  the  circumstances.  But,  due  to  the  short 
duration  of  Sprints,  cancellation  rarely  makes  sense. 

When  a Sprint  is  cancelled,  any  completed  and  "Done"  Product  Backlog  items  are  reviewed.  If 
part  of  the  work  is  potentially  releasable,  the  Product  Owner  typically  accepts  it.  All  incomplete 
Product  Backlog  Items  are  re-estimated  and  put  back  on  the  Product  Backlog.  The  work  done  on 
them  depreciates  quickly  and  must  be  frequently  re-estimated. 

Sprint  cancellations  consume  resources,  since  everyone  has  to  regroup  in  another  Sprint 
Planning  to  start  another  Sprint.  Sprint  cancellations  are  often  traumatic  to  the  Scrum  Team, 
and  are  very  uncommon. 
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Sprint  Planning 

The  work  to  be  performed  in  the  Sprint  is  planned  at  the  Sprint  Planning.  This  plan  is  created  by 
the  collaborative  work  of  the  entire  Scrum  Team. 

Sprint  Planning  is  time- boxed  to  a maximum  of  eight  hours  for  a one-month  Sprint.  For  shorter 
Sprints,  the  event  is  usually  shorter.  The  Scrum  Master  ensures  that  the  event  takes  place  and 
that  attendants  understand  its  purpose.  The  Scrum  Master  teaches  the  Scrum  Team  to  keep  it 
withinthe  time-box. 

Sprint  Planning  answers  the  following: 

• What  can  be  delivered  in  the  Increment  resulting  from  the  upcoming  Sprint? 

• How  will  the  work  needed  to  deliver  the  Increment  be  achieved? 

Topic  One:  What  can  be  done  this  Sprint? 

The  DevelopmentTeam  works  to  forecast  the  functionality  that  will  be  developed  duringthe 
Sprint.  The  Product  Owner  discusses  the  objective  that  the  Sprint  should  achieve  and  the 
Product  Backlog  items  that,  if  completed  in  the  Sprint,  would  achieve  the  Sprint  Goal.  The  entire 
Scrum  Team  collaborates  on  understanding  the  work  of  the  Sprint. 

The  input  to  this  meeting  is  the  Product  Backlog,  the  latest  product  Increment,  projected 
capacity  of  the  DevelopmentTeam  duringthe  Sprint,  and  past  performance  of  the  Development 
Team. The  numberof  items  selected  fromthe  Product  Backlog  forthe  Sprintis  solely  uptothe 
DevelopmentTeam.  Only  the  DevelopmentTeam  can  assess  what  it  can  accomplish  over  the 
upcomingSprint. 

After  the  DevelopmentTeam  forecasts  the  Product  Backlog  items  it  will  deliver  in  the  Sprint,  the 
Scrum  Team  crafts  a Sprint  Goal.  The  Sprint  Goal  is  an  objective  that  will  be  met  withinthe 
Sprint  through  the  implementation  of  the  Product  Backlog,  and  it  provides  guidance  to  the 
DevelopmentTeam  on  why  itis  buildingthe  Increment. 

Topic  Two:  How  will  the  chosen  work  get  done? 

Havingsetthe  SprintGoal  and  selectedthe  Product  Backlogitemsforthe Sprint, the 
DevelopmentTeam  decides  how  it  will  build  this  functionality  into  a "Done"  product  Increment 
duringthe  Sprint.  The  Product  Backlog  items  selected  for  this  Sprint  plus  the  plan  for  delivering 
them  is  called  the  Sprint  Backlog. 

The  DevelopmentTeam  usually  starts  by  designing  the  system  and  the  work  needed  to  convert 
the  Product  Backlog  into  a working  product  Increment.  Work  may  be  ofvaryingsize,  or 
estimated  effort.  However,  enough  work  is  planned  during  Sprint  Planning  for  the  Development 
Team  to  forecast  what  it  believes  it  can  do  in  the  upcoming  Sprint.  Work  planned  for  the  first 
days  of  the  Sprint  by  the  DevelopmentTeam  is  decomposed  by  the  end  of  this  meeting,  often  to 
units  of  one  day  or  less.  The  DevelopmentTeam  self-organizes  to  undertake  the  work  in  the 
Sprint  Backlog,  both  during  Sprint  Planning  and  as  needed  throughout  the  Sprint. 
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The  Product  Owner  can  help  to  clarify  the  selected  Product  Backlog  items  and  make  trade-offs. 
If  the  Development  Team  determines  it  has  too  much  or  too  little  work,  it  may  renegotiate  the 
selected  Product  Backlogitems  with  the  Product  Owner.  The  DevelopmentTeam  mayalsoinvite 
other  people  to  attend  in  order  to  provide  technical  or  domain  advice. 

By  theendof  the  SprintPlanning,the  DevelopmentTeam  should  beabletoexplaintothe 
Product  Ownerand  Scrum  Masterhow  itintendsto  work  as  a self-organizingteamto 
accomplish  the  Sprint  Goal  and  create  the  anticipated  Increment. 

Sprint  Goal 

The  SprintGoal  isan  objective  setforthe  Sprintthatcan  be  metthrough  the  implementation  of 
Product  Backlog.  It  providesguidancetothe  DevelopmentTeamonwhyitis  buildingthe 
Increment.  It  is  created  during  the  Sprint  Planning  meeting.  The  SprintGoal  gives  the 
DevelopmentTeam  some  flexibility  regardingthe  functionality  implemented  within  the  Sprint. 
The  selected  Product  Backlog  items  deliver  one  coherent  function,  which  can  be  the  SprintGoal. 
The  SprintGoal  can  be  any  othercoherence  thatcausesthe  DevelopmentTeamto  work 
together  ratherthan  on  separate  initiatives. 

As  the  DevelopmentTeam  works,  it  keeps  the  SprintGoal  in  mind.  In  ordertosatisfy  the  Sprint 
Goal,  it  impl  ements  the  functionality  and  technology.  If  the  work  turns  out  to  be  different  than 
the  DevelopmentTeam  expected,  they  collaborate  with  the  Product  Owner  to  negotiate  the 
scope  of  Sprint  Backlog  within  the  Sprint. 
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Daily  Scrum 

The  DailyScrum  isa  15-minute  time-boxed  eventforthe  DevelopmentTeamtosynchronize 
activities  and  create  a plan  for  the  next  24  hours.  This  is  done  by  inspecting  the  work  since  the 
last  DailyScrum  and  forecastingthe  work  that  could  be  done  before  the  nextone. 

The  DailyScrum  is  held  at  the  same  time  and  place  each  day  to  reduce  complexity.  Du  ring  the 
meeting,  the  DevelopmentTeam  membersexplain: 

• What  did  I do  yesterday  that  helped  the  DevelopmentTeam  meetthe  SprintGoal? 

• What  will  I do  today  to  helpthe  DevelopmentTeam  meetthe  Sprint  Goal? 

• Do  I see  any  impediment  that  prevents  me  or  the  DevelopmentTeam  from  meeting  the 
SprintGoal? 

The  DevelopmentTeam  usesthe  DailyScrumto  inspectprogresstoward  the  SprintGoal  andto 
inspect  how  progress  is  trending  toward  completing  the  work  in  the  Sprint  Backlog.  The  Daily 
Scrum  optimizesthe  probability  thatthe  DevelopmentTeam  will  meet  the  Sprint  Goal.  Every 
day, the  DevelopmentTeam  should  understand  howitintendstoworktogetherasa  self- 
organizingteamtoaccomplishthe  SprintGoal  and  create  the  anticipated  Increment  by  the  end 
of  the  Sprint.  The  DevelopmentTeam  or  team  members  often  meet  immediately  after  the  Daily 
Scrum  fordetailed  discussions,  orto  adapt,  or  replan,  the  rest  of  the  Sprint's  work. 

The  Scrum  Master  ensuresthatthe  DevelopmentTeam  hasthe  meeting,  butthe  Development 
Team  is  responsible  for  conducting  the  Daily  Scrum.  The  Scrum  Master  teaches  the 
DevelopmentTeam  to  keep  the  Daily  Scrum  within  the  15-minute  time-box. 

The  Scrum  Master  enforces  the  rule  that  only  DevelopmentTeam  members  participate  in  the 
DailyScrum. 

Daily  Scrums  improve  communications,  eliminate  other  meetings,  identify  impediments  to 
developmentforremoval,  highlightand  promote  quick  decision-making,  and  improve  the 
Development  Team's  level  of  knowledge.  This  isa  key  inspect  and  adapt  meeting. 


Sprint  Review 

A Sprint  Review  is  held  atthe  end  ofthe  Sprintto  inspectthe  Incrementand  adaptthe  Product 
Backlog  if  needed.  During  the  Sprint  Review,  the  Scrum  Team  and  stakeholders  collaborate 
about  what  was  done  in  the  Sprint.  Based  on  that  and  any  changes  to  the  Product  Backlog 
during  the  Sprint,  attendees  collaborate  on  the  next  things  that  could  be  done  to  optimize  value. 
This  is  an  informal  meeting,  not  a status  meeting,  and  the  presentation  ofthe  Increment  is 
intended  to  elicit  feed  back  and  foster  collaboration. 

This  is  a four-hour  time- boxed  meeting  for  one-month  Sprints.  For  shorter  Sprints,  the  event  is 
usually  shorter.  The  Scrum  Master  ensuresthatthe  event  takes  place  and  that  attendants 
understand  its  purpose.  The  Scrum  Master  teaches  all  to  keep  it  within  the  time -box. 
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The  Sprint  Review  includes  the  following  elements: 


• Attendees  include  the  Scrum  Team  and  key  stakeholders  invited  by  the  Product  Owner; 

• The  Product  Owner  explains  what  Product  Backlog  items  have  been  "Done"  and  what  has 
not  been  "Done"; 

• The  Development  Team  discusses  what  went  well  during  the  Sprint,  what  problems  it  ran 
into,  and  how  those  problems  were  solved; 

• The  Development  Team  demonstrates  the  work  that  it  has  "Done"  and  answers  questions 
aboutthe  Increment; 

• The  Product  Owner  discusses  the  Product  Backlog  as  it  stands.  He  or  she  projects  likely 
completion  dates  based  on  progress  to  date  (if  needed); 

• The  entire  group  collaborates  on  what  to  do  next,  so  that  the  Sprint  Review  provides 
valuable  input  to  subsequent  Sprint  Planning; 

• Reviewof  howthe  marketplace  or  potential  useofthe  product  might  have  changed  what  is 
the  most  valuable  thingtodo  next;and, 

• Reviewof  the  timeline,  budget,  potential  capabilities,  and  marketplace  for  the  next 
anticipated  release  of  the  product. 

The  result  of  the  Sprint  Review  is  a revised  Product  Backlog  that  defines  the  probable  Product 

Backlog  items  for  the  next  Sprint.  The  Product  Backlog  may  also  be  adjusted  overall  to  meet  new 

opportunities. 


Sprint  Retrospective 

The  Sprint  Retrospective  is  an  opportunity  for  the  Scrum  Team  to  inspect  itself  and  create  a plan 
for  improvements  to  be  enacted  duringthe  nextSprint. 

The  Sprint  Retrospective  occurs  after  the  Sprint  Review  and  prior  to  the  next  Sprint  Planning. 
This  is  a three -hour  time-boxed  meeting  for  one- month  Sprints.  For  shorter  Sprints,  the  event  is 
usually  shorter. The  Scrum  Master  ensuresthatthe  eventtakes  place  and  that  attendants 
understand  its  purpose.  The  Scrum  Master  teaches  all  to  keep  it  within  the  time -box.  The  Scrum 
Master  participates  as  a peer  team  member  in  the  meeting  from  the  accountability  over  the 
Scrum  process. 

The  purpose  of  the  Sprint  Retrospective  isto: 

• Inspecthowthe  lastSprintwent  with  regardsto  people,  relationships,  process, and  tools; 

• Identify  and  orderthe  majoritemsthat  went  well  and  potential  improvements;  and, 

• Create  a plan  for  implementing  improvements  to  the  way  the  Scrum  Team  does  its  work. 
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The  Scrum  Master  encourages  the  Scrum  Team  to  improve,  within  the  Scrum  process 
framework,  its  development  process  and  practices  to  make  it  more  effective  and  enjoyable  for 
the  next  Sprint.  During  each  Sprint  Retrospective,  the  Scrum  Team  plans  ways  to  increase 
product  quality  by  adapting  the  definition  of  "Done"  as  appropriate. 

By  the  end  of  the  Sprint  Retrospective,  the  Scrum  Team  should  have  identified  improvements 
that  it  will  implement  in  the  next  Sprint.  Implementing  these  improvements  in  the  next  Sprint  is 
the  adaptation  to  the  inspection  of  the  Scrum  Team  itself.  Although  improvements  may  be 
implemented  at  anytime,  the  Sprint  Retrospective  provides  a formal  opportunity  to  focus  on 
inspection  and  adaptation. 


Scrum  Artifacts 

Scrum's  artifacts  represent  work  or  value  to  provide  transparency  and  opportunities  for 
inspection  and  adaptation.  Artifacts  defined  by  Scrum  are  specifically  designed  to  maxi  mize 
transparency  of  key  information  so  that  everybody  has  the  same  understanding  of  the  artifact. 

Product  Backlog 

The  Product  Backlog  is  an  ordered  list  of  eve rything  that  might  be  needed  in  the  product  and  is 
the  single  source  of  requirementsforanychangestobe  made  to  the  product. The  Product 
Owneris  responsibleforthe  Product  Backlog,  including  its  content,  availability,  and  ordering. 

A Product  Backlog  is  never  complete.  The  earliest  development  of  it  only  lays  out  the  initially 
known  and  best-understood  requirements.  The  Product  Backlog  evolves  as  the  product  and  the 
environment  in  which  it  will  be  used  evolves.  The  Product  Backlog  is  dynamic;  it  constantly 
changesto  identify  whatthe  product  needsto  be  appropriate,  competitive,  and  useful.  As  long 
as  a product  exists,  its  Product  Backlog  also  exists. 

The  Product  Backlog  lists  all  features,  functions,  requirements,  enhancements,  and  fixes  that 
constitute  the  changesto  be  made  to  the  product  in  future  releases.  Product  Backlog  items  have 
the  attributes  of  a description,  order,  estimate  and  value. 

As  a product  is  used  and  gains  value,  and  the  marketplace  provides  feedback,  the  Product 
Backlog  becomes  a largerand  more  exhaustive  list.  Requirements  neverstop  changing,  so  a 
Product  Backlog  is  a living  artifact.  Changes  in  business  requirements,  market  conditions,  or 
technology  may  cause  changes  in  the  Product  Backlog. 

Multiple  Scrum  Teams  often  work  together  on  the  same  product.  One  Product  Backlog  is  used 
to  describe  the  upcoming  work  on  the  product.  A Product  Backlog  attribute  that  groups  items 
may  then  be  employed. 
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Product  Backlog  refinement  is  the  act  of  adding  detail,  estimates,  and  order  to  items  in  the 
Product  Backlog. This  is  an  ongoing  process  in  which  the  Product  Ownerand  the  Development 
Team  col  laborate  on  the  details  of  Product  Backlog  items.  During  Product  Backlog  refinement, 
items  are  reviewed  and  revised.  The  Scrum  Team  decides  how  and  when  refinement  is  done. 
Refinement  usually  consumes  no  more  than  10%  of  the  capacity  of  the  Development  Team. 
However,  Product  Backlogitems  can  be  updated  at  any  time  by  the  Product  Owneror  at  the 
Product  Owner's  discretion. 

Higher  ordered  Product  Backlog  items  are  usually  clearer  and  more  detailed  than  lower  ordered 
ones.  More  precise  estimates  are  made  based  on  the  greater  clarity  and  increased  detail;  the 
lower  the  order,  the  less  detail.  Product  Backlog  items  that  will  occupy  the  Development  Team 
for  the  upcoming  Sprint  are  refined  so  that  any  one  item  can  reasonably  be  "Done"  within  the 
Sprinttime-box.  Product  Backlogitems  that  can  be  "Done"  by  the  DevelopmentTeam  within 
one  Sprintare  deemed  "Ready" forselection  in  a Sprint  Planning.  Product  Backlogitems  usually 
acquire  this  degree  of  transparency  through  the  above  described  refiningactivities. 

The  DevelopmentTeam  isresponsibleforall  estimates.  The  ProductOwnermay  influence  the 
DevelopmentTeam  by  helping  it  understand  and  select  trade-offs,  but  the  people  who  will 
perform  the  work  make  the  final  estimate . 

Monitoring  Progress  Toward  a Goal 

At  any  point  in  time,  the  total  work  remaining  to  reach  a goal  can  be  summed.  The  Product 
Owner  tracks  this  total  work  remaining  at  I east  every  Sprint  Review.  The  Product  Owner 
compares  this  amount  with  work  remaining  at  previous  Sprint  Reviews  to  assess  progress 
toward  completing  projected  work  by  the  desired  time  forthe  goal  .This  information  is  made 
transparentto  all  stakeholders. 

Various  projective  practices  upon  trending  have  been  used  to  forecast  progress,  like  burn- 
downs,  burn-ups,  orcumulative  flows.  These  have  proven  useful.  However,  these  do  not  replace 
the  importance  of  empiricism.  In  complex  environments,  what  will  happen  is  unknown.  Only 
what  has  happened  may  be  usedforforward-lookingdecision-making. 


Sprint  Backlog 

The  Sprint  Backlog  is  the  set  of  Product  Backlog  items  selected  forthe  Sprint,  pi  us  a pi  an  for 
delivering  the  product  Increment  and  realizing  the  Sprint  Goal.  The  Sprint  Backlog  is  a forecast 
by  the  DevelopmentTeam  about  what  functionality  will  be  in  the  next  Increment  and  the  work 
needed  to  deliver  that  functionality  into  a "Done"  Increment. 

The  Sprint  Backlog  makes  visibleall  ofthe  workthatthe  DevelopmentTeam  identifiesas 
necessary  to  meetthe  Sprint  Goal. 
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The  Sprint  Backlog  is  a plan  with  enough  detail  that  changes  in  progress  can  be  understood  in 
the  Daily  Scrum.  The  DevelopmentTeam  modifies  the  Sprint  Backlog  throughoutthe  Sprint,  and 
the  Sprint  Backlog  emerges  during  the  Sprint.  This  emergence  occurs  as  the  DevelopmentTeam 
works  through  the  plan  and  learns  more  about  the  work  needed  to  achieve  the  Sprint  Goal. 

As  new  work  is  required,  the  DevelopmentTeam  adds  itto  the  Sprint  Backlog.  As  work  is 
performed  or  completed,  the  estimated  remaining  work  is  updated.  When  elements  of  the  plan 
are  deemed  unnecessary,  they  are  removed.  Only  the  DevelopmentTeam  can  change  its  Sprint 
Backlogduringa  Sprint. The  Sprint  Backlog  isa  highly  visible,  real-time  pictureof  the  work  that 
the  DevelopmentTeam  plans  to  accomplish  during  the  Sprint,  and  it  belongs  solely  to  the 
DevelopmentTeam. 

Monitoring  Sprint  Progress 

At  any  point  in  time  in  a Sprint,  the  total  work  re  main  ingin  the  Sprint  Backlog  can  be  summed. 
The  DevelopmentTeam  tracks  this  total  work  remaining  at  least  for  every  Daily  Scrum  to  project 
the  likelihood  of  achieving  the  Sprint  Goal.  By  tracking  the  remaining  work  throughout  the 
Sprint,  the  DevelopmentTeam  can  manage  its  progress. 

Increment 

The  Increment  is  the  sum  of  all  the  Product  Backlog  items  completed  during  a Sprint  and  the 
value  of  the  increments  of  all  previous  Sprints.  At  the  end  of  a Sprint,  the  new  Increment  must 
be  "Done,"  which  means  it  must  be  in  useable  condition  and  meet  the  Scrum  Team's  definition 
of  "Done."  It  must  be  in  useable  condition  regardless  of  whether  the  Product  Owner  decides  to 
actually  release  it. 


Artifact  Transparency 

Scrum  relies  on  transparency.  Decisions  to  optimize  value  and  control  risk  are  made  based  on 
the  perceived  state  of  the  artifacts.  To  the  extent  that  transparency  is  complete,  these  decisions 
have  a sound  basis.  To  the  extent  that  the  artifacts  are  incompletely  transparent,  these 
decisions  can  be  flawed,  value  may  diminish  and  risk  may  increase. 

The  Scrum  Master  must  work  with  the  Product  Owner,  DevelopmentTeam,  and  other  involved 
parties  to  understand  if  the  artifacts  are  completely  transparent.  There  are  practices  for  coping 
with  incompletetransparency;  the  Scrum  Master  must  help  everyone  apply  the  most 
appropriate  practices  in  the  absence  of  complete  transparency . A Scrum  Master  can  detect 
incompletetransparency  by  inspectingthe  artifacts,  sensing  patterns,  listeningclosely  to  what  is 
beingsaid,  and  detectingdifferences  between  expected  and  real  results. 

The  Scrum  Master's  job  is  to  work  with  the  Scrum  Team  and  the  organization  to  increase  the 
transparency  of  the  artifacts.  This  work  usually  involves  learning,  convincing,  and  change. 
Transparency  doesn't  occurovernight,  butisa  path. 
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Defi nition  of  "Done" 

When  a Product  Backlog  item  or  an  Increment  is  described  as  "Done",  everyone  must 
understand  what  "Done"means.  Although  thisvariessignificantly  perScrumTeam,  members 
must  have  a shared  understanding  of  what  it  means  for  work  to  be  complete,  to  ensure 
transparency.  This  is  the  definition  of  "Done"  for  the  Scrum  Team  and  is  used  to  assess  when 
work  is  complete  on  the  product  Increment. 

The  same  definition  guides  the  Development  Team  in  knowing  how  many  Product  Backlog  items 
it  can  select  during  a Sprint  Planning.  The  purpose  of  each  Sprint  is  to  deliver  Increments  of 
potentially  releasable  functionality  that  adhere  to  the  Scrum  Team's  current  definition  of 
"Done." 

Development  Teams  deliver  an  Increment  of  product  functionality  every  Sprint.  This  Increment 
is  useable,  so  a Product  Owner  may  choose  to  immediately  release  it.  If  the  definition  of  "done" 
for  an  increment  is  part  of  the  conventions,  standards  or  guide  lines  of  the  development 
organization,  all  Scrum  Teams  must  follow  it  as  a minimum.  If  "done  "for  an  increment  is  not  a 
convention  of  the  development  organization,  the  Development  Team  of  the  Scrum  Team  must 
define  a definition  of  "done"  appropriate  forthe  product.  If  there  are  multiple  Scrum  Teams 
workingon  the  system  or  product  release,  the  development  teams  on  all  of  the  Scrum  Teams 
must  mutually  definethe  definition  of  "Done." 

Each  Incrementisadditiveto  all  prior  Increments  and  thoroughly  tested,  ensuringthatall 
Increments  worktogether. 

As  Scrum  Teams  mature,  it  is  expected  that  their  definitions  of  "Done"  will  expand  to  include 
more  stringent  criteria  for  higher  quality.  Anyone  product  or  system  should  have  a definition  of 
"Done"  that  is  a standard  for  any  work  done  on  it. 


End  Note 

Scrum  isfree  and  offered  inthis  Guide.  Scrum's  roles,  artifacts,  events,  and  rulesare  immutable 
and  although  im  pie  me  nting  only  parts  of  Scrum  is  possible,  the  result  is  not  Scrum.  Scrum  exists 
only  in  its  entirety  and  functions  well  as  a container  for  other  techniques,  methodologies,  and 
practices. 
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pride. 
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